Skip to content

Add other input types for SQLAlchemy BIT model#137

Open
jackrua wants to merge 10 commits intopgvector:masterfrom
jackrua:feature/other_inputs_for_sqlalchemy_bit
Open

Add other input types for SQLAlchemy BIT model#137
jackrua wants to merge 10 commits intopgvector:masterfrom
jackrua:feature/other_inputs_for_sqlalchemy_bit

Conversation

@jackrua
Copy link
Contributor

@jackrua jackrua commented Jul 17, 2025 •
edited
Loading

Hi,

First of all, thank you for the great library @ankane!

I'm opening this PR to address some issues that have been raised by users (#84, #110 and #112), that is to input types other than string in the BIT SQLAlchemy model (also when using the asyncpg dialect). In brief with this PR, given:

class Item(Base):
    id = mapped_column(Integer, primary_key=True)
    binary_embedding = mapped_column(BIT(3))

You can add it to your database using whatever input you like (and this will be transformed following the logic already present in the init of the Bit class):

with Session(engine) as session: 
   session.add(Item(id = 1, 
   binary_embedding = [True, False, True])) # or [1, 0, 1], or np.array([1, 0, 1])

@jackrua jackrua changed the title Add other input types for SQLAlchemy models Add other input types for SQLAlchemy BIT model Jul 17, 2025
ankane added a commit that referenced this pull request Sep 2, 2025
@ankane @jackrua
Added support for str objects for bit type with SQLAlchemy - #137
33dee60 
Co-authored-by: Giacomo rua <[email protected]>
@ankane
Copy link
Member

ankane commented Sep 2, 2025

Hi @jackrua, thanks for the PR. Added support for passing str objects in the commit above. I think the other changes are breaking to some degree, but may make sense for 0.5.0.

@jackrua
Copy link
Contributor Author

jackrua commented Sep 22, 2025 •
edited
Loading

Thank you @ankane for the feedback and sorry for the late response. I merged master in my branch and updated my PR, and now the CI passes too.

However, I was thinking that now when you read from the DB using the sqlalchemy model, we are returning str in some cases and BitString in others, wouldn't it be better to always return a Bit object (similar to what you do with HALFVEC for example), what do you think?
I wanted to implement the result_processor method to fix this in this PR but I wasn't sure what you thought about it, let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@jackrua @ankane